rustdoc: never link to unnamable items #143849
Conversation
rustbot
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
lolbinarycat
force-pushed
the
rustdoc-priv-normalize-143222
branch
from
fb01811 to
950634d
Compare
lolbinarycat
changed the title
|
rustbot has assigned @GuillaumeGomez. Use |
rustbot
added
S-waiting-on-review
| type Ty = Bar; | ||
| } | ||
| pub struct Bar; | ||
| }; |
There was a problem hiding this comment.
Do we need to have this as a dependency for this test? Can't it be done within the current crate?
There was a problem hiding this comment.
Also, what happens if the const is named X?
There was a problem hiding this comment.
The bug only happens during cross-crate re-exports. Otherwise a separate failsafe kicks in.
I was under the impression that the _ was a delibraerately injected placeholder, but maybe it is just the constant name, if so we'll need a more principled approach.
There was a problem hiding this comment.
Ok, yeah, you're right, my assumptions were wrong. Just looking at the path isn't enough.
There was a problem hiding this comment.
Need to check what kind of item (block more precisely) the parent is. If it's not a module, then it's likely wrong.
There was a problem hiding this comment.
any idea what datastructure would retain that info in the cross-crate case? I'm somewhat struggling to understand how we even reconstruct path info and such from an rlib.
There was a problem hiding this comment.
Path doesn't matter here, you need to check what is its parent.
This comment has been minimized.
This comment has been minimized.
lolbinarycat
force-pushed
the
rustdoc-priv-normalize-143222
branch
from
ef5c252 to
0952022
Compare
| /// Checks if the given defid refers to an item that is unnamable, such as one defined in a const block. | ||
| fn is_unnamable(tcx: TyCtxt<'_>, did: DefId) -> bool { | ||
| let mut cur_did = did; | ||
| while let Some(parent) = tcx.opt_parent(cur_did) { |
There was a problem hiding this comment.
I think this code is wrong: we can link to an impl associated item even if the impl is in a const/function block.
There was a problem hiding this comment.
right, i think impls should break with a return false and only modules should continue up...
well technically we can only link to an impl item if the thing being impl'd on is nameable, but i'm not sure if that's something observable.
There was a problem hiding this comment.
Just discovered that we can have modules in any blocks. Dark magic. XD
There was a problem hiding this comment.
Also, if the item is not public, it'll be stripped so should be fine. (for impl block as parents)
fixes #143222